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REMARKS 

Claims 1 to 9 are pending. Claims 1, 8 and 9 are amended to emphasize that 
programming properties of programming objects are reflected through graphical 
properties of graphical elements. No new issues are raised by these amendments 
since they merely amplify or emphasize the nature of the invention. 

Claims 1 to 9 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
U.S. Patent No. 5,883,639 to Walton et al. ("Walton"). This rejection is again 
traversed for the reason that Walton does not show the claimed invention. 

The claimed invention is directed to a visual programming language in which 
programming objects in memory are represented as graphical objects on a display and 
wherein when program properties of the programming objects change, changes are 
induced in the graphical properties of the visual representation of the object on the 
display. The invention is used in static program analysis which aims at determining 
properties of the behavior of a program without actually executing it. Static analysis 
is founded on the theory of abstract interpretation for proving the correctness of 
analyses with respect to the semantics of a programming language. An analysis can 
often be divided into two phases: 

1 . A first phase in which a program is translated into a system of equations or 
constraints over a partial order of program properties. The solutions to the 
system represent correct information about the particular property which is 
being analyzed. 

2. A second resolution phase in which an actual solution is calculated. This 
phase can rely on either general iterative work-set algorithms or on more 
domain-specific symbolic resolution techniques. 

The disclosed and claimed invention is directed to a specific aid in such static 
program analysis. 

Figure 3 shows a block diagram of a visual programming language of the 
present invention. This diagram illustrates programming object state reflection, A 
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display 400 depicts visual representations 440, 450 and 460 of the programming 
objects 470, 480 and 490 in memory 410. The visual programming language 
executable 430 maintains the relationships between the visual representations and the 
programming objects. In the course of programming with the programming objects 
470, 480 and 490, the states of these programming objects may change. For example, 
the data they represent may not be initialized, or they may be set to some default 
values. Through program analysis or other means, general characteristics may be 
determined, for example, that their values may be within a certain set of values or 
ranges. This all depends upon the nature of the variables, and the values they may be 
assigned. When for a given programming object, at any point in programming, 
characteristics such as these are determined, it is said that the programming object's 
programming state is determined. These programming states can induce changes in 
the graphical properties of the visual representation of the object. By way of 
illustration, if a programming object is known to have been set to some default value, 
the color of some related graphical element might be set to red. This process is 
known as state reflection, and this process is the essence of the claimed invention. 

In contrast, Walton discloses a visual software engineering system which uses 
a concept of defining both input to and output from graphical objects in an 
object-oriented system by providing examples of what the user desires the graphical 
object to do. This technique is referred to by Walton as "animation by example". In 
this process, the user creates a user interface by drawing the user interface with a 
graphics editor and then defining the output behavior (i.e., graphics manipulation) of 
the user interface components by showing each state or frame as an animation. This 
is accomplished by changing the object using a graphic editor function such as move 
or rotate and storing each of the frames with the object as a behavior state. Just as 
with defining the output, the input is defined by giving the graphic object an example 
of what type of input to look for, and once it finds that input, it tells the object which 
frame to output or change to. Application code can then drive the animation or read 
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the input by accessing the frame numbers assigned to each of the example frames. 
(See Abstract of Walton) 

Thus, Walton discloses a visual software engineering system for providing a 
means of creating user interfaces to products under development without the need of 
a programming language. On a graphical interface, the user designs a user interface, 
including visual artifacts such as buttons, check boxes, etc. These visual entities are 
managed by "graphical objects". A graphical object is not a generic programming 
object, but rather is an object subject to enablement. For a given set of visual objects, 
the user sets buttons, moves dials, etc., and when a desired visual state is found, the 
user "snapshots" that visual state, gives it a name, and all this state information plus 
name is stored as a "frame" with the graphical object. The user does this any number 
of times. Similarly, input can be defined on the graphical object "by example", which 
the graphical object later detects as a trigger to set up a specific state based on a 
specific user-specified "frame". 

To summarize, the Walton graphical object is/has the following: 

1) A well defined object for managing graphical interfaces. 

2) Maps to graphical representations. 

3) Stores "frames" or visual states of a user interface. 

4) Maps user input (mouse, etc.) to frames. 

Finally, with reference to column 8, lines 54-56, Walton states "The resulting 
objects are then stored as objects in an object-oriented database system and connected 
to other objects or user code ..." This is how the graphical object is related to user 
code. Essentially, the user code has to "connect to" or invoke the graphical objects. 
The means are not precise, and do not need to be. What is important is that the 
graphical objects are not user code defined objects; rather, they are service objects to 
the user application program. 

A distinguishing feature of the disclosed invention is found in the 
specification on page 9, beginning at line 16, wherein implicitly the programming 
objects (variables, objects) are part of an existing or developing application program. 
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What this means is that the state or program property of the programming object, say 
at a line in the program, is derived from some kind of code analysis (data flow, 
control flow, pointer, etc.). State is very broadly put, but includes things like 
initialization state (set/unset/ "set to 3") or known ranges (x is between 3 and 9). The 
claims have been amended to use the term "program property" rather than "state" to 
better clarify what is being analyzed. The present invention describes the mechanism 
for displaying that change in a program property of a programming element.. 
In contrast to Walton, 

1) The claimed object refers to user application objects (variables, etc.), not the 
specific graphical object as described in Walton; 

2) The program property of the programming object is derived from a program 
context and the state is displayed. This is the opposite direction from Walton, 
who defines state and stores it, and maps actions. The former is a reflective 
paradigm, while the latter is more of a constructive paradigm. 

These distinctions have been clearly set out in the claims and are now 
emphasized by the amendments to the independent claims. Specifically, claim 1 
recites a "computer implemented method of visual representation of programming 
objects as graphical elements, wherein program properties of said programming 
objects are reflected through graphical properties of graphical elements" (emphasis 
added). The method comprises three steps. The first step is "detecting a change in a 
program property of a programming object in visual representation and shown 
visually on a display device as one or more graphical elements, wherein graphical 
elements represent the programming object and program properties of programming 
objects are reflected through graphical element properties" (emphasis added). The 
second step is "determining graphical aspect changes that apply to graphical 
elements of the programming object appropriate for the change in a program 
property of the programming object" (emphasis added). The third step "applying the 
graphical aspect changes to corresponding graphical elements, wherein the graphical 
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aspect changes include changes in color, position and size." This last step is the 
process of state reflection "wherein programming properties of programming objects 
are reflected through graphical properties of graphical elements", as recited in the 
preamble. 

As explained above, Walton does not contemplate the process of state 
reflection as a result of detecting a change in state of a data element representing a 
programming object. 

Claim 8 recites an "apparatus for visual representation of programming 
objects as graphical elements". This apparatus comprises "a data processing system 
comprising a display device, an interactive device, as in a keyboard, a pointing device, 
a storage device, and a data processor", a "memory coupled to the data processor via a 
bidirectional bus, wherein the memory includes a first memory section for at least one 
program and a second memory section for data", "computer code . . .", and "means 
for displaying a visual representation of a plurality of graphical elements on the 
display device. . ." The computer code comprises "a visual programming language, 
wherein the computer code is stored in the first memory section, and the computer 
code detects a change in a program property of a programming object, determines 
graphical aspect changes that apply to graphical elements which represent the 
programming object, and applies graphical aspect changes to said visual 
representation of said programming object which represents the change of the 
program property of the programming object" (emphasis added). The "displayed 
graphical elements represent programming objects and program properties of 
programming objects are reflected through displayed graphical element properties." 
Thus, claim 8 similarly defines over Walton. 

Claim 9 is similar to claim 1, but is directed to a machine readable medium 
containing code for performing the method of claim 1. The language of claim 9 is 
otherwise similar to that of claim 1 . 
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In view of the foregoing, it is respectfully requested that the application be 
reconsidered, that claims 1 to 9 be allowed, and that the application be passed to 
issue. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
personal interview. 

A provisional petition is hereby made for any extension of time necessary for 
continued pendency during the life of this application. Please charge any fees for 
such provisional petition and any deficiencies in fees and credit any overpayment of 
fees to Attorney's Deposit Account 50-0510 (IBM-Yorktown). 



Respectfully submitted, 




Clyde R Christofferson 
Reg. No. 34,138 
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